Computer systems often include additional devices used to provide additional functionality. These devices, often called “peripheral” devices, may include keyboards, printers, scanners, network interface and graphics cards, modems, monitors, cameras, sound input devices, and the like. Generally, device drivers (software programs that convert the more general input/output instructions of the operating system into messages that the devices can understand) control the peripheral devices. Many device drivers are built into the operating system of the computer and device drivers that are not already in the operating system typically need to be added.
In some network environments, peripheral devices may not be coupled directly to the computer system through an expansion bus (e.g., Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), S-Bus, VersaModule Eurocard (VME) bus), but rather through a network connection, via a so-called “thin” or “ultra-thin” client. In a thin or ultra-thin-client environment, it may not be possible to embed device-specific code, such as device drivers, for the large number of devices available.
In addition, in some network environments (e.g., a thin-client architecture), data and computational functionality are provided by data sources via a centralized processing arrangement. In this arrangement, all computing is performed by one or more servers acting as the central data sources independently of the destination of the data being generated. These servers may constitute a single point of failure for a potentially large pool of users and thereby jeopardizing system reliability and performance.
Grouping addresses the problem of single point failure by enabling multiple servers to share management of a set of appliances (or devices). In other words, if one server in the group fails, functions performed by the failed server may be redistributed to the other servers in the system. To distribute load across multiple servers and for re-distribution after a server failure, all devices should be equally accessible to every server. In addition, consistency should be maintained when servers fail, meaning that a failed server should not affect programs that are running on other servers nor should the failed server affect devices that are in use. In general, uninterrupted operation of the devices should be maintained.
Connecting devices to applications in a grouped server system may be challenging because an individual device may be managed (e.g., identified, made available, protected) by a different server. For example, using a broadcast-based shared database for device location service fails to consistently propagate information (e.g., device availability, allocation, and removal) with low latency (e.g., <1 second). In a broadcast system, each server has a mirror of the shared databases which are often lazily updated (e.g., several mods per day rather than several mods per minute). Multiple servers are used only during transition states.
Another scheme for device location services is a database which is shared among all the servers wanting to locate services. This type of database handles transactions relatively quickly, but pose a single point of failure.
Yet another scheme for device location services is a distributed, replicated database that has low-latency transaction ability and does not pose a single point of failure. However, a distributed, replicated database is difficult to construct and involves high synchronization overhead.